Mobile telecommunications networks enable users of User Equipment (UE) to communicate with other such users via one of a number of nodes B (NB) and a core network.
In the recent developments of mobile network infrastructure, new protocols were necessary in order to support dense deployments of telecommunication equipment and the increasing number of users.
In that context, LTE is a standard for wireless communication of high-speed data for mobile phones and data terminals. It is based on the GSM/EDGE and UMTS/HSPA network technologies, increasing the capacity and speed using new modulation techniques. The standard is developed by the 3GPP (3rd Generation Partnership Project) and is meanly specified in its Release 8 document series.
e-UTRAN is the radio access network of 3GPP's Long Term Evolution mobile networks. It is the abbreviation for “evolved UMTS Terrestrial Radio Access Network”, also referred to as the 3GPP work item on the Long Term Evolution, called LTE, also known as the “Evolved Universal Terrestrial Radio Access” whose acronym is E-UTRA.
Under the 3GPP standards, a UTRAN base station is referred to as a Node B and an E-UTRAN base station is referred to as an eNode B or eNB.
A “Node B” corresponds to a base transceiver station also known as BTS used in the GSM network. Node B can be noted as NB in the following description.
The FIG. 1 describes an e-UTRAN architecture where an eNB allows aggregating data communications from user's equipment UE to the core network through downstream and upstream links 1 via switches SW. The switch can be a mobility management entity noted MME and especially a MME/S-GW when it is used as a gateway to the core network.
FIG. 1 illustrates an architecture where eNB allow horizontal links between each other.
The eNBs are interconnected with each other by means of the X2 interface. The eNBs are also connected by means of the S1 interface to the EPC (Evolved Packet Core), more specifically to the MME (Mobility Management Entity) by means of the S1-MME interface and to the Serving Gateway (S-GW) by means of the S1-U interface. The S1 interface supports a many-to-many relation between MMEs/Serving Gateways and eNBs.
Recently the 3GPP standards body has adopted an official architecture and started work on a new standard for home base stations. Where the home base station is operating in accordance with the LTE standards, the Home Base Station is sometimes referred to as an HeNB. A similar architecture will also be applied in the WiMAX network. In this case, the home evolved node B is commonly referred to as a femto cell.
For simplicity, the present application will use the term HeNB to refer to any such home base station. The HeNB will typically provide radio coverage (for example, 3 G/4 G/WiMAX) within the home but may also be used in an enterprise, a mall, or outdoor. It will connect to the core network via a suitable public network (for example via an ADSL link to the Internet) and in the case of the 3GPP standards, via an optional HeNB gateway (HNB-GW) which typically will aggregate traffic from several HeNBs.
In the following description, different eNB types are discussed:    Macro-eNB is used as a synonym for any eNB deployed and maintained by the operator based on its own requirements.    Home eNB, called HeNB, is best described as a Pico eNB of only one cell which, when at home, is typically installed by the end-user and has lower transmit power. The HeNB possibly only requires a subset of the operations and maintenance functionality required for the Macro-eNBs. The Home eNB may be deployed on the same frequency layer as the macro cell, as well as a different layer, and may also be restricted to only a closed user group.
FIG. 2 illustrates a typical E-UTRAN architecture comprising:    switch as referred as MME/S-GW to access to the core network;    eNB allowing:            connections with the switches via S1 interface;        connections with other eNB via X2 interface.            HeNB allowing local deployment of mobile access to the network, the HeNB comprising:            connections with the switches via S1 interface, for example with specific switches, noted HeNB GW, in order to access to the core network;        connections with others HeNB via X2 interface.        
In the scenario of dense deployment of HeNBs, the number of HeNB neighbors to a macro eNB may become large, several hundred for instance.
The X2AP protocol is used to handle the UE (User Equipment) mobility within e-UTRAN and provides especially the following functions:                Mobility Management;        Load Management;        Reporting of General Error Situations;        Resetting the X2;        Setting up the X2;        eNB Configuration Update.        
X2AP acronyms means “X2 Application Protocol”. The X2AP protocol is implemented over the X2 interface. The main functions of X2 interface layer 1 are as following:                Interface to physical medium;        Frame delineation;        Line clock extraction capability;        Transmission quality control;        Layer 1 alarms extraction and generation.        
Drawing and maintaining such number of X2 connections can become challenging for the macro eNB in particular with regards to drawing and maintaining such high number of SCTP associations with its neighbors. In the following description SCTP acronym means “Stream Control Transmission Protocol”. It is a transport layer protocol, serving in a similar role to the other transport layer protocols.
This issue is currently being addressed as part of 3GPP Enhanced H(e)NB Mobility Study Item Release 11.
As part of this work, three proxy solutions have been proposed.
The first solution presents the advantage that it works only in SCTP routing protocol and does not interfere with the X2AP solution. The proxy router does not need to terminate X2AP protocol. On the other hand, eNB, HeNB and the proxy have to use a non standardized SCTP which doesn't exist today. All nodes must be modified to be compliant with this solution.
The second solution fully terminates the X2AP protocol in the proxy but presents the advantage to reuse an off-the-shelf standard SCTP. Such a solution presents the inconvenience that a proxy presents high complexity and maintains all X2AP contexts and nodal behavior.
The third solution called “X2 routing proxy” solution presents the advantage that it works on top of existing SCTP also while remaining stateless in terms of termination of the X2AP protocol, i.e. no X2AP contexts stored in the proxy and no X2AP nodal behavior implemented.
However an impediment has been found for this solution when a HeNB switches off. Indeed, there is no means to inform the peer X2AP entity in the macro eNB that this HeNB is no longer reachable. This means that the macro eNB will continue sending X2AP messages and requests expecting an answer that will never come.
No real solution has been presented so far to efficiently tackle this problem. The best existing solution by default is therefore that the macro eNB could detect after multiple triggering of unanswered X2AP class 1 procedures, i.e. procedures for which an answer is expected by the requesting node, that something got wrong on the peer X2AP HeNB.
One inconvenience is that the eNB implementation relies on choices made in the macro eNB implementation which may not have implemented this kind of detection mechanism. Then it does not cover the case of the class 2 procedure, i.e. X2AP procedures for which no answer is expected by the requesting node.
A major drawback of current solutions results from the increased number of undesirable message which saturates the network.